This invention pertains to telecommunications, and particularly to establishing an interface in a telecommunications network that includes relative small cells known as femtocells.
In a typical cellular radio system, wireless terminals (also known as mobile stations and/or user equipment units (UEs)) communicate via a radio access network (RAN) to one or more core networks. The wireless terminals can be mobile stations or user equipment units (UE) such as mobile telephones (“cellular” telephones) and laptops with wireless capability, e.g., mobile termination, and thus can be, for example, portable, pocket, hand-held, computer-included, or car-mounted mobile devices which communicate voice and/or data with radio access network.
The radio access network (RAN) covers a geographical area which is divided into cell areas, with each cell area or group of cell areas being served by a base station, a radio base station (RBS), which in some networks is also called “NodeB” or “Node B”. A cell is a geographical area where radio coverage is provided by the radio base station equipment at a base station site. Each cell is identified by an identity within the local radio area, which is broadcast in the cell. The base stations communicate over the air interface operating on radio frequencies with the user equipment units (UE) within range of the base stations.
In some versions of the radio access network, several base stations are typically connected (e.g., by landlines or microwave) to a radio network controller (RNC). The radio network controller, also sometimes termed a base station controller (BSC), supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks.
The Universal Mobile Telecommunications System (UMTS) is a third generation mobile communication system, which evolved from the Global System for Mobile Communications (GSM), and is intended to provide improved mobile communication services based on Wideband Code Division Multiple Access (WCDMA) access technology. UTRAN is essentially a radio access network using wideband code division multiple access for user equipment units (UEs). The Third Generation Partnership Project (3GPP) has undertaken to evolve further the UTRAN and GSM based radio access network technologies.
Specifications for the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) are ongoing within the 3rd Generation Partnership Project (3GPP). Another name used for E-UTRAN is the Long Term Evolution (LTE) Radio Access Network (RAN).
Long Term Evolution (LTE) is a variant of a 3GPP radio access technology wherein the radio base stations are connected directly to a core network rather than to radio network controller (RNC) nodes. In general, in LTE the functions of a radio network controller (RNC) node are performed by the radio base stations nodes. As such, the radio access network (RAN) of an LTE system has an essentially “flat” architecture comprising radio base stations without reporting to radio network controller (RNC) nodes.
The evolved UTRAN (E-UTRAN) comprises evolved base stations, e.g., evolved NodeBs or eNodeBs or eNBs, providing evolved UTRA user-plane and control-plane protocol terminations toward the wireless terminal. The eNB hosts the following functions (among other functions not listed): (1) functions for radio resource management (e.g., radio bearer control, radio admission control), connection mobility control, dynamic resource allocation (scheduling); (2) selection of a mobility management entity (MME) when no routing to an MME can be determined from the information provided by the user equipment unit (UE); and (3) User Plane functions, including IP Header Compression and encryption of user data streams; termination of U-plane packets for paging reasons, and switching of U-plane for support of UE mobility. The eNB hosts the PHYsical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers. The latter includes the functionality of user-plane header-compression and encryption. The eNodeB also offers Radio Resource Control (RRC) functionality corresponding to the control plane. The eNodeB performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL QoS, cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packet headers.
The core network where E-UTRAN is connected to is called the Evolved Packet Core (EPC), a.k.a. System Architecture Evolution (SAE) network. Both the E-UTRAN and the EPC comprise together the Evolved Packet System (EPS) that is also known as the SAE/LTE network. As indicated above, a base station in this concept is called eNodeB or eNB (E-UTRAN NodeB).
The specifications/studies for Long Term Evolution (LTE) and System Architecture Evolution (SAE) also include the possibility of having an E-UTRAN base station to provide home or small area coverage for a limited number of users. Such a home or small area coverage base station is herein also called HeNB (Home eNodeB). For UTRAN (WCDMA), this type of home access point is called HNB (Home NodeB).
The HeNB can provide normal radio services for the end users in home or small area coverage and can be connected to the mobile core network using, e.g., some kind of IP based transmission. As used herein, the radio coverage provided by the HeNB is called a “femtocell”.
An example impetus for providing femtocell-type of local access is to provide cheaper call or transaction rates/charges for a wireless terminal when connected via the HeNB as compared to when the wireless terminal is connected via the eNB. Another impetus is reducing the load on the operator's eNBs and backhaul connections, thereby reducing the operator's capital expenditures and operating expenditures.
The HeNB can, in most cases, use the end user's already existing broadband connection (e.g. xDSL, Cable) to achieve connectivity to the operators mobile core network and possibly to other eNBs/HeNBs. Over the broadband connection and other possible intermediate IP networks (e.g. in the internet) a HeNB communicates with the core network nodes in the operator's network via an IPsec tunnel (Internet Protocol security architecture according to RFC 4301), which is established between the HeNB and a Security Gateway (SEGW), which protects the border of the operator's network.
FIG. 1 shows an exemplary LTE/SAE network with both femtocells and macrocells. FIG. 1 shows also a HeNB concentrator node (another name used for the HeNB concentrator node is HeNB-GW (HeNB Gateway). Although not shown in FIG. 1, in at least some configurations a Security Gateway (SEGW) can be logically placed between the HeNB and the HeNB-GW and can serve for terminating IPsec tunnels from the HeNB. FIG. 1 also shows the LTE radio access network (RAN) interfaces S1 (to the core network (CN)). and X2 (between eNBs/HeNBs). For simplicity, in FIG. 1 interface X2 is only shown between eNBs.
FIG. 2 shows the nodes and the interfaces in LTE radio access network (RAN) in more detail. In FIG. 2 it is assumed that at least the control plane of the X2 interface (X2-CP) to/from a HeNB passes the HeNB Concentrator Node (also named for example the HeNB Gateway (HeNB-GW)).
The X2 interface between eNBs is mainly used for one kind of handover, often called ‘X2-initiated handover’. When interface X2 is set up between two eNBs, a list of information on the cells served by an eNB is sent to the other eNB, and vice versa. Interface X2 is set up only between eNBs that serve cells between which handover may be performed. The protocol that is used on the X2 interface, i.e. the X2 Application Protocol (X2AP), includes various messages, including two messages known as the “X2 SETUP REQUEST” message and the “X2 SETUP RESPONSE” message. These two messages are defined to accommodate a maximum 256 served cells per eNB. The X2AP protocol also includes an “ENB CONFIGURATION UPDATE” message, which serves to update the served cell information. The maximum number of served cells per eNB for the “ENB CONFIGURATION UPDATE” message is also limited to 256.
Referring to FIG. 2, in the conventional practice of setting up the X2 interface between eNB_1 and eNB_2, information on the macrocells MC_1.1 to MC_1.m is sent from eNB_1 to eNB_2 and information on the macrocells MC_2.1 to MC_2.m is sent from eNB_2 to eNB_1. As indicated above, the maximum number of served cells has to be equal to or less than 256 for eNBs.
Yet a mobile network may have several hundreds of thousands (e.g., on the order of about 1 million) of HeNBs. It would be unreasonable to expect that the core network control nodes, e.g., Mobility Management Entities (MMEs) with their control part of S1s (S1-MMEs), would be able to handle so many HeNBs. Therefore, one purpose of the HeNB-GW (see FIG. 2) is to conceal the large number of HeNBs from the core network (CN). The HeNB-GW will, from the viewpoint of the core network CN (S1 interface), look like one eNB with many cells (even though cells are not really visible in the core network). The HeNB-GW will act as an eNB proxy for all the HeNBs that are connected to the HeNB-GW. From the viewpoint of a HeNB, the HeNB-GW will look like the core network (and also like the S1 interface). Similar reasoning is valid for the control part of the X2 interface (X2-CP); the HeNB-GW will look like one eNB with many cells from another eNB.
The number of HeNBs connected to a HeNB-GW is likely to be up to several tens of thousands (e.g., on the order of one hundred thousand) as the number of HeNB-GWs in a full network (e.g., on the order of one million HeNBs) should not exceed a few tens (e.g., on the order of ten). Thus the number of femtocells “served” by a HeNB-GW (an eNB proxy) may be up to a few hundreds of thousands (e.g., on the order of two hundred thousand), assuming a HeNB serves a few (e.g., two or so) femtocells. The HeNB-GW will maintain the list of the femtocells it is “serving” and the information per cell required for the X2 interface setup. This list is updated each time a HeNB is connected to or disconnected from the HeNB-GW.
The number of HeNBs and thus femtocells “below” a HeNB-GW may be very large (several tens of thousands). This means that the list of cell information from a HeNB-GW to an eNB at the setup of the X2 interface may contain very many cells. The number of cells supported by the present standardized signaling over the X2 interface is limited to 256.
Referring to FIG. 2 and the conventional proposal, when setting up the X2 interface between eNB_1 and HeNB-GW_3, information on the macrocells MC_1.1 to MC_1.m (where m is likely to be less than 10 but certainly less than 256) is sent from eNB_1 to HeNB-GW_3 and information on the femtocells FC_31.1 to FC_39.n is sent from HeNB-GW_3 to eNB_1. FIG. 2 shows the general case with several femtocells served by a HeNB (cells FC_31.1 to FC_31.n is served by HeNB_31). In a normal scenario it is likely that a HeNB will serve only one cell (n would be equal to 1). As the number of femtocells “served” by a HeNB-GW may be much larger than 256 (several tens of thousands), the standardized procedures for the X2 interface are not feasible. Even if the maximum number of served cells in the used X2AP messages is increased from 256 in order to cope with the large number of served cells, it will not be feasible for an eNB to receive and store information on several tens of thousands of neighbor femtocells.
Besides, the number of femtocells may not be stable. The HeNBs for the femtocells are typically located at the end-users' premises beyond control of the operator. An end-user may disconnect and then re-connect the HeNB whenever the end-user so desires. This means that the list of cell information may be updated frequently and thus causing excessive signaling load in the neighbor eNBs.
A way to cope with the problem of the large number of HeNB-GW “served cells” in the X2 interface is not to use ‘X2 initiated handover’ but instead ‘S1 initiated handover’. For the latter, the X2 interface control plane (X2-CP) is not needed. Rather, the signaling between eNBs needed for handover is accomplished in the S1 control plane (S1-MME) via a control node in core network, e.g., an MME. The current assumption in 3GPP is that this type handover shall be used for handovers involving a HeNB. However, this may cause severe signaling and processing load in the MMEs.